A database stores data and permits access to the data using, for example, queries to the database. In general, the database includes tables formed from columns and rows. The columns define a structure of each table by specifying which data elements are included within each row of the tables. The rows define individual data records within each table that are comprised of data elements defined by the columns. Thus, a table has a set of defined columns and a variable number of rows depending on how many records are in a given table. Because data may be added and deleted from tables, the number of records/rows may fluctuate. Moreover, the records themselves may be modified during operation. Consequently, the data of the database is in flux and may change over time.
Furthermore, a database may electronically store records that include general textual information (e.g., medical records), map data (e.g., satellite images) or application metadata (e.g., configuration metadata) that defines various aspects of how an application executes. The application metadata may not be modified as frequently as other types of data (e.g., medical records); however, over the lifecycle of the application, developers may wish to iteratively update the application metadata to improve functionality and add new features to the application. Because the application actively uses the application metadata from the database while executing, a whole separate copy of the database may be implemented for development purposes to avoid interfering with operation of the application. In other words, the database may be copied so that the developers can iterate changes without impacting how the application is presently executing in a production environment for end users.
However, maintaining an additional development database is cumbersome and costly. Additionally, other difficulties still persists such as each developer editing the database independently causing conflicts between separate developers. Thus, even though a separate development database may be implemented, this does not solve all of the difficulties but instead shifts the difficulties to a separate space. Consequently, separate workspaces may be used to provide for independent development of separate portions of the development database without interference. However, present workspace solutions are database system dependent. That is, each separate database system is produced by a different vendor and includes separate idiosyncrasies. Thus, the workspace solutions are also specific to the particular database system and do not function when applied to different database systems since they are developed specifically for a certain vendor. This lack of cross-platform compatibility severely complicates implementing solutions for development by multiple individuals within a single database.